Domain Knowledge in Planning: Representation and Use

Planning systems rely on knowledge about the problems they have to solve: The problem description and in many cases advice on how to find a solution. This paper is concerned with a third kind of knowledge which we term domain knowledge: Information about the problem that is produced by one component of the planner and used for advice by another. We first distinguish domain knowledge from the problem description and from advice, and argue for the advantages of the explict use of domain knowledge. Then we identify three classes of domain knowledge for which these advantages are most apparent and define a language, DKEL, to represent these classes. DKEL is designed as an extension to PDDL. Knowledge in Planning The knowledge input to a planning system may be divided in two distinct classes: problem specification and advice. The problem specification in turn typically consists of two parts: (1) a description of the means at the planners disposal, such as the possible actions that may be taken and resources that may be consumed, and (2) the goals to be achieved, including possibly a measure that should be optimized, constraints that should never be violated, and so on. Advice we term knowledge, of all kinds, intended to help the planner find a better solution, find it more quickly or even to find a solution at all. There is often a certain difficulty in distinguishing the two, particularly since the same kind of knowledge, indeed the very same statement, may sometimes play one role and at other times another: e.g. constraints may be part of a problem specification, but there are also several planners that accept advice formulated as constraints. Nevertheless, two things always distinguish advice from the problem specification: First, the problem specification defines what is a solution, advice does not. It may well be possible to find good solutions while ignoring, or even acting in conflict with, the given advice, and conversely, heeding poor advice may cause a planner to fail to find a solution even though one exists. It is, however, obviously never possible to find a solution in violation of the problem specification. Second, the problem specification is, at least in theory, independent of the planning system used, or even of the fact that an automated planner is being used at all (apart from the fact that the specification must be expressed in a format understandable by the planner). What constitutes useful advice, by contrast, tends to be highly dependent on the type of planning system used. Languages for Specification and Advice Any automated planning system needs a means of accepting as input a problem specification, and in most cases this means is language. Consequently, many different planning problem specification languages, with a varying degree of similarity, have been used, but recently, PDDL (McDermott et al. 1998; Bacchus 2000; Fox & Long 2002b) has emerged as a kind of de facto standard. On a “specification vs. advice” scale, PDDL is strongly oriented towards specification, and even as a specification language, it has its shortcomings: there is for example no easy way to specify constraints, which, as mentioned above, may be an important part of a problem. To combat these shortcomings, several extensions of PDDL (or PDDL-like languages) have been proposed: PDDL2.1 (Fox & Long 2002b) adds the ability to express temporal and metric properties of actions as well as metric goals. PCDL (Baioletti, Marcugini, & Milani 1998) extends PDDL with a constraint vocabulary, which is then “compiled away” into standard PDDL. Many planners have added their own specific extensions, e.g. for constraints (Huang, Selman, & Kautz 1999) or invariants (Refanidis & Vlahavas 2001), and many use altogether different languages, e.g. to allow the expression of non-determinism (Bertoli et al. 2001) or of more elaborate action and resource models (Chien et al. 2000). Languages for expressing plan constraints, whether they be specification or advice, tend to be quite closely related to the kind of planning algorithm used. Examples include Hierarchical Task Network (HTN) schemas, which have a long tradition as a means of expressing plan constraints (Tate 1977; Wilkins 1990; Nau et al. 1999; Wilkins & desJardins 2000), and more recently different temporal logics, as in e.g. TLPlan (Bacchus & Kabanza 2000) and TALplanner (Kvarnstrom & Doherty 2001). Planners capable of accepting as input control knowledge of other kinds also use mostly specific languages. This is a natural consequence of the fact that the knowledge itself tends to be highly planner-specific.